第4回 HashiCorp User Group Meetup に参加してきました #hashicorpjp

第4回 HashiCorp Meetupに参加してきました､様子をレポートします｡

#勉強会

加藤諒

2018.12.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

おはようございます､加藤です｡タイトルの通り､HashiCorp Meetupに参加してきました､様子をレポートします｡

概要

2018/12/17（月）19:00 - 21:45
株式会社ドリコム　セミナールーム
- 東京都目黒区下目黒1丁目8-1　アルコタワー 17F

時間	タイトル
18:30 - 19:00	受付、ネットワーキング
19:00 - 19:20	HashiCorp stackについて、超総合的な話とご挨拶伊藤仁智,　HashiCorp Japan株式会社　シニアソリューションエンジニア

19:20 - 19:40	「僕と契約して、Terraform少女になってよ (仮)」大原常徳様,　株式会社ドリコム　enza事業本部プラットフォーム開発部部長
19:40 - 19:50	休憩
19:50 - 20:10	「オンプレミスの鍵管理の要にVault Enterpriseを導入しようとしている話」松井賢人様,　ヤフー株式会社　アイデンティティ＆アクセスマネジメント部開発1 プロダクトオーナー
20:10 - 20:30	「DMMの動画の可用性を支えるConsul」菊地弘晃様, 合同会社DMM. com 動画配信事業部配信基盤スクラムチーム Web/アプリエンジニア
20:30 - 20:50	「The Tao of HashiCorp 再入門～正しい努力のための足がかり～」前佛雅人様, さくらインターネット株式会社, テクノロジーエバンジェリスト twitter ID @zembutsu
20:50 - 21:00	ラップアップ Brian Burns,　HashiCorp Japan株式会社　ゼネラルマネージャー
21:00 - 21:45	ネットワーキングパーティー

セッション内容

HashiCorp stackについて、超総合的な話とご挨拶

HashiCorpには4つのミッションがあり､それぞれが製品に対応している｡
Vagrant､PackerはHashiCorpでの開発は頻繁に行わずオープンソースに寄贈したと考えている｡

Provision(Terraform)
- 専用マシンを用意する時代からオンデマンドでマシンを調達する時代へ移り変わった
- マルチクラウド + SaaSという利用形態が普及してきた
- 大量のインスタンスを依存関係を考えてデプロイするのは大変
- Terraformはこれらの問題を解決
- AWS, GCP, Azure Alibaba
- Fastly, k8s, Datadog, etc...
Security(Vault)
- 従来のセキュリティは城を作るイメージ(境界セキュリティ)
- マルチクラウド + SaaS で実現するのは大変
- IPベースからIDベースへ変わってきている
- Vaultで新世代のセキュリティを実現する
- シークレットの一元管理
- IDベースのセキュリティ
- IDP
  - AD, Github, etc...と連携
- ポリシー
  - 許可する事を定義
- シークレットエンジン
  - ポリシーに基づいてシークレットを発行
  - 動的・静的なシークレット
  - 証明書
Run(Nomad)
- 密結合だったアプリケーションが疎結合に変わってきている
- 複雑なデプロイ作業が必要
- デプロイ・アップデートのスケジューリング
- インフラを意識しないアプリケーションを開発を実現
Connect(Consul)
- リソース(サービス)は動的に増減する為ホスト(IPアドレス)で決め打つ事ができなくなってきている
- ホストベースからサービスベースに変わってきている
- Consulがサービスディスカバリを行いサービス間の接続(名前解決)を提供する
  - サービス間のAuthorization
  - サイドカープロキシ
  - 既存のサービスに変更を加えなくて良い
  - mTLSコネクション
  - コンフィグのデプロイ・サービスのリスタート
  - リアルタイムでのコンフィグ・環境変数の変更

まとめ

	Static	Dynamic
アプリケーション Run Nomad	密結合	疎結合
ネットワーク Connect Consul	ホストベース	サービスベース
セキュリティ Secure Vault	IPベース	IDENTITYベース
インフラ Provision Terraform	専用	オンデマンド

「僕と契約して、Terraform少女になってよ (仮)」

Terraform Enterpiseを11月から導入
- 元々OSS版を使用していた
AWSリソースの本番適用をterraformで行っている
Terraformだけではなく他のツールと組み合わせて使用している
- Packer
- awsspec, serverspec
- itamae, Ansible
- serverless framework
Terraform Enterprise利用前の運用フロー
- ブランチ
- master branch: plan & apply
- master 以外: planだけ
- backend
- S3
- lock
- DynamoDB
- 実行
- Circle CI
問題点
- stateファイルの管理(たまに壊れる)
- ローカル
  - stateファイルのバージョン管理が面倒
- リモート
  - S3が別途必要
  - バージョン管理ができない
- apply/planの同時実行時のリソースバッティング(排他処理の仕組みが必要)
- DynamoDBのテーブルを使って排他処理(Lock)
- ロールバックが簡単にできない
- stateファイル自体が壊れるとサービス普及までに著しく時間がかかる
- Terraformのアップデートが大変
Enterpriseへ移行した主な理由
- Team managemenet
- チーム単位でメンバーを管理
- チーム単位でWorkSpaces(1個のTerraformファイル群)への操作権限を設定
  - Permission(Read/Plan/Write/Admin)
- Remote run & state
- stateファイルをcloudで管理できる
- stateのバージョン管理が可能
- どのバージョンのterraformでplan/applyするか指定可能
- Sentinel, policy as code management
- アクセスポリシーを評価するF/W
- Policy as Code(ポリシーをコードで管理する)
  - Terraformのコードがポリシーに従っているかチェックする
  - 特定のタグをリソースに必須で付ける
まとめ
- Terraformの外で頑張っていたのをTerraform Enterpriseに集約できた
- ロールバックの敷居が下がった
- Policy as Codeでより固いインフラ構築ができるようになった
- CI/CDや権限管理など属人化しやすい作業をTerraform Enterpriseが行ってくれる

「オンプレミスの鍵管理の要にVault Enterpriseを導入しようとしている話｣

クラウド全盛のこの時代だが様々な要因でオンプレミスは捨てきれない
- 社内ポリシー
- 既存資産がある
- etc...
オンプレミスでもクラウドに負けないプラットフォームを提供したい!
- 鍵管理の要としてVault Enterpriseを使おうとしている(特殊な使い方)
VaultをEncryption as a Serviceとして使用する
- なんで直接使わないのか
- 社内独自のエコシステムに組み込むため
- 全てのリクエストに対応しようとすると沢山のVault Nodeが必要そうだった
パフォーマンスを担保する為に
- Read Replica
- 1クラスタあたりのReadパフォーマンスを上げる
- Performance Replication
- リクエストを処理できるアクティブなクラスターを増やす
- Disaster Recovery Replication
- データセンターに丸ごと障害が発生しても止まらない

「DMMの動画の可用性を支えるConsul」

Consulって｢コンサル｣・｢コンスル｣どっちの発音?
- 会場では｢コンサル｣が多数
規模感
- トラフィック: 200Gbps超
- 再生数(VOD:) 4億/年
再生ボタンを押下してからの流れを最近リプレイス!
- 再生URLの生成をAPI化(st-api)
再生URLが生成できない = ユーザーが再生できない
- 高可用性が求められる(登壇者の見解)
- 最大分間 4000 再生が行われる
- 50回再生が行われないとユーザーからのクレームが発生し始める
- 止まるとヤバイ
死活管理をConsulで行う
- st-apiはDBも含むディープヘルスチェックできるチェックAPIを持つ
- Consulはこれを叩く
- 異常があるとGo製のツールを使ってRoute53のレコードを変更
Redis(センチネル)のフェイルオーバーにConsulを使用する
- Consul DNSを使用
- notification scriptを使用する
- 30行弱のPythonで実現できた!
まとめ
- Consulで死活監視→Route53のAPIでサービスイン・アウトを制御細かい監視と柔軟なサービスイン・アウトを実現!
- Redisの自動フェイルオーバー時のmaster再接続
- 超シンプルなスクリプトで再接続を実装
参考リンク
- DMM動画サービスの問題を解決しようとしている話（再生URL生成API編） - DMM inside

「The Tao of HashiCorp 再入門～正しい努力のための足がかり～」

The Tao of HashiCorp再入門 from Masahito Zembutsu

The Tao of HashiCorpとは
- HashiCorpのロードマップ・プロダクトデザインの指標
- Workflows, not Technologies
- ワークフローにおける最終ゴールに焦点をあてる
- 既存のツールがなければ設計､構築する
- そこに至る最適な技術を採用する
- Simple, Modular, Composable
- Unix哲学として広く知られているものと同じアプローチ
- 特定の役割を持つツール郡を､同時に使えるようにする
- 問題全体の解決ではなく､分解した要素の解決を目指す
- ユーザーフレンドリー!必要な物だけ使用できる!
- Immutability
- Versioning through Condification
- 全ての手順をコードで下記､保管し､バージョン管理する
- システムに対する変更は､自動的に記録されるべき
- まさにTerraform
- Automation through COndification
- Resilent system
- Pragmatism
- 実用主義こそが､あらゆる問題を解決すると信じている
- 現在の手法を利用者に押し付けるものであってはいけない
- より適した方法､正しい方法があれば､見直す
参考リンク
- The Tao of HashiCorp 日本語参考訳 | Pocketstudio.jp log3